home account info subscribe login search FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Search this book:
 
Previous Table of Contents Next


Understand Visual Basic’s Optimizations

The Visual Basic compiler provides several optimization features that you should understand. These optimizations apply when you create a compiled executable. Using some of the optimizations, you may be able to improve your program’s performance without making any changes to the code.

Be very careful when you use these options. They disable checks that allow Visual Basic to detect certain conditions and raise errors. They seriously weaken Visual Basic’s ability to recover from errors.

For example, if you disable array bounds checking, Visual Basic cannot tell when the program tries to access an array element that lies outside of the array. In that case, the program cannot catch the error using an On Error statement. If you are lucky, the program will crash without warning. If you are unlucky, it will modify some other piece of memory that lies where the missing array entry would be if it existed. That can create a bug that is extremely hard to find.

Because these optimizations apply only to the compiled version of the program, they can make the program’s compiled and noncompiled versions behave differently. That can lead to some bugs that are very hard to detect and fix.

To access the advanced optimizations in Visual Basic 5 and 6, select the Project Properties command from the bottom of the Project menu. Select the Compile tab and then click the Advanced Optimizations button to see the dialog shown in Figure 11.1.


Figure 11.1  Visual Basic’s Advanced Optimizations dialog.

The advanced optimizations are described in the following sections.

Assume No Aliasing

This option tells Visual Basic that no variable is referenced by more than one name at the same time. For example, suppose you pass a parameter declared by reference using the ByRef keyword to a routine. The routine knows the variable by the parameter’s name. The calling routine knows the variable by its original name. Within the MySub routine shown in the following code, the variable A is referred to by the name A and X at the same time.

Private A As Integer

Private Sub Caller()
    MySub A
End Sub

Private Sub MySub(ByRef X As Integer)
    ‘ Here the variable is known as A and X.
       :
End Sub

This optimization allows Visual Basic to make the code run faster. It will not necessarily work, however, unless the code never uses aliased names.

You should not use this optimization unless you never pass parameters ByRef. Keep in mind that ByRef is the default, so the following definition of MySub is just as dangerous as the previous one.

Private Sub MySub(X As Integer)
     ‘ Here the variable is known as A and X.
    :
End Sub

Remove Array Bounds Checks

This option disables Visual Basic’s array bounds checks. Normally, Visual Basic checks array accesses to ensure that the access is within the array’s bounds. If the program tries to access an index outside the array’s bounds, Visual Basic generates a subscript out of range error.

If you disable array bounds checking, Visual Basic does not make this check. If the program tries to access an entry outside the array’s bounds, the program may crash. Even worse, it may write over the piece of memory that lies where the missing array entry should be.

Error handlers cannot catch this error. If this check is disabled, the following code may crash the program. If array bounds checks are enabled as usual, the error handler catches the error and presents a message box.

Private Sub UnsafeSub()
Dim arr(1 To 5) As Integer
Dim i As Integer

    On Error GoTo OutOfBounds

    ‘ Access items outside the array’s bounds.
    For i = 1 To 10
    arr(i) = i
    Next i
    Exit Sub

OutOfBounds:
    MsgBox “Error” & Str$(Err.Number) & _
       vbCrLf & Err.Description
End Sub

Disable array bounds checks only if you have thoroughly tested your program and you are certain it never tries to access elements outside of any array. Of course, if the program uses no arrays, it cannot violate array bounds so you can disable array bounds checks.

Remove Integer Overflow Checks

Normally, Visual Basic checks every integer calculation to see if the result is too big to fit in an integer. If it finds that the result will overflow the integer data type, Visual Basic raises an overflow error.

If you disable this option, the program will not notice the error and it will perform the calculation anyway. When the system performs an operation that overflows, the result can be quite strange. For example, 20,000 + 20,000 = 40,000. The largest value that can fit in an integer is 32,767, so calculating 20,000 + 20,000 normally causes an integer overflow. If you disable integer overflow checks, the result is –25,536.

If you run the following code with integer overflow checks enabled, the program catches the overflow and presents an error message. If you disable integer overflow checks, the code displays the value –25,536.

Private Sub UnsafeSub()
Dim A As Integer

    On Error GoTo OverflowError
    A = 20000 + 20000
    MsgBox Format$(A)
    Exit Sub

OverflowError:
    MsgBox “Error” & Str$(Err.Number) & _
    vbCrLf & Err.Description
End Sub

Disable integer overflow checks only if you have thoroughly tested your program and you are certain it never performs integer operations that may result in an overflow. If the program never uses integer calculations, you can disable integer overflow checks.

Remove Floating-Point Error Checks

Just as it checks for integer overflow errors, Visual Basic examines floating-point calculations looking for errors. It checks for values out of range and divide by zero errors. If you disable floating-point error checks, the program will not notice these errors and the program may generate some strange results.

For example, if you execute the following code with floating-point checks disabled, the code sets the value of A to a special infinite value. Then the message box displays the string “1.#INF.” If you run the code with floating-point checks enabled, Visual Basic catches the error and presents a division by zero error message.

Private Sub UnsafeSub()
Dim A As Single

    On Error GoTo FloatError
    A = 10 / 0
    MsgBox Format$(A)
    Exit Sub

FloatError:
    MsgBox “Error” & Str$(Err.Number) & _
    vbCrLf & Err.Description
End Sub

Disable floating-point checks only if you have thoroughly tested your program and you are certain it never performs floating-point operations that may result in an error. If the program does not use any floating-point operations, you can disable floating-point checks. However, keep in mind that Visual Basic may automatically promote integer values to floating-point values. For example, the following code does not directly use any floating-point values. When it reaches the statement A = 10 / 0, Visual Basic decides that the result of the division should be a floating-point number. The result is a divide by zero error that Visual Basic cannot catch if floating-point checks are disabled.

Private Sub UnsafeSub()
Dim A As Variant

    On Error GoTo FloatError
    A = 10 / 0
    MsgBox Format$(A)
    Exit Sub

FloatError:
    MsgBox “Error” & Str$(Err.Number) & _
    vbCrLf & Err.Description
End Sub


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-1999 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.